In communication networks, such as cellular networks as specified by 3GPP (3rd Generation Partnership Project), it is known to provide various kinds of packet based services to a UE (user equipment), such as multimedia telephony services or messaging services. For example, in a 3GPP network such services may be provided by an architectural framework referred to as IMS (Internet Protocol Multimedia Subsystem). Details of the IMS are for example specified in 3GPP TS 23.228 V12.7.0 (2014-12). The IMS, but also various other kinds of packet based services, involve utilization of a control plane protocol referred to as SIP (Session Initiation Protocol), as for example specified in IETF RFC 3261 (June 2002), for establishing a session between a client utilizing the service and a server providing the service.
In many cases, the communication network may provide multiple application servers which provide multiple different services. Such application servers may have different capacities and the utilization of the provided service may vary individually for each application server. Accordingly, overload situations may occur in which one or more of the application servers is overloaded while one or more others of the application servers are not overloaded.
For addressing overload situations, the SIP provides a throttling mechanism based on a retry-after time window indicated in a header of a failure message. In the case of the IMS, the throttling mechanism may for example be implemented at a node acting as a proxy node for SIP messages between the IMS client and an IMS CN (IMS core network) and the application servers, such as a P-CSCF (Proxy Call Session Control Function) and IBCF (Interconnect Border Control Function). Further details concerning the handling of SIP messages by the P-CSCF and the IBCF can for example be found in 3GPP TS 24.229 V12.6.0 (2014-09).
Such proxy node typically operates on the basis of “windows” of SIP requests which are currently being handled. When the window is full, the proxy node does not forward the SIP request to the IMS CN but responds to it with an SIP failure response with response code 503 (Service Unavailable). This SIP failure response indicates that the server is undergoing maintenance or is temporarily overloaded and therefore cannot process the request. A “Retry-After” header field may specify when the client may reattempt its request. Upon receiving the SIP failure response, the client will not reattempt a new SIP request but will wait for the time period indicated in the Retry-After header field before sending a new SIP request. Such throttling mechanism may be implemented on an SIP method level, i.e., the windows and Retry-After time window may be provided individually for different SIP methods, such as REGISTER, SUBSCRIBE, or INVITE.
However, in the above-mentioned situations where an overload occurs only for a part of the different application servers, the existing throttling mechanism may provide unsatisfactory results: It is quite common that different services use the same SIP method. For example, MMTel (Multimedia Telephony) and RCS (Rich Communication Suite) group chat both utilize the SIP INVITE method. Nonetheless, the corresponding application servers may have different capacity and may be subject to different traffic load. Accordingly, in an exemplary overload scenario the application server for RCS group chat may be overloaded while the application server for MMTel is not overloaded. If in this situation a UE tries to establish an RCS group chat session by sending an SIP INVITE request, the proxy node would respond with an SIP 503 failure response. If the UE then sends a further SIP INVITE request to establish an MMTel session, the proxy node may send an SIP 503 failure response as well, even though the corresponding application server is not overloaded. Further, 3GPP TS 24.229, section 5.1.3.1 specifies that upon receiving a SIP 503 failure response containing a Retry-After header field, the UE shall not automatically reattempt the request until after the time period indicated by the Retry-After header field has expired. Therefore, the UE may refrain from even sending the SIP INVITE request to establish the MMTel session. Accordingly, one service may be rejected due to an overload which is actually only present with respect to another service. This is undesirable from the perspective of service availability and user experience.
Accordingly, there is a need for techniques which allow for efficiently controlling multiple services in a communication network.